home *** CD-ROM | disk | FTP | other *** search
/ Gekkan Dennou Club 147 / Gekkan Dennou Club - 2000.8 Vol. 147 (Japan).7z / Gekkan Dennou Club - 2000.8 Vol. 147 (Japan) (Track 1).bin / docs / ippon / struct.doc < prev    next >
Encoding:
Text File  |  2000-07-07  |  4.6 KB  |  131 lines
  1. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  2.  
  3.              ゲームプログラムの構造
  4.  
  5. ────────────────────────────────────
  6.  
  7.  
  8. ▼ 大きなプログラムを作るには
  9.  
  10.  
  11.   今回作るゲームプログラムはソフトウェア的に見ると中規模プログラムです。
  12. 何をもって中規模と言えるのかは不明ですが、大規模なシステムと言えるほどの
  13. ものではなく、かと言って小物プログラム程度のものではありません。
  14.  
  15. 　中規模プログラムとは感覚的に言って、
  16.  
  17.     ・実行形式が１００ＫＢ以上
  18.     ・ソースリスト(*.c)が１０ファイル以上
  19.  
  20.   …とこんなところでしょうか。小物プログラムであれば即興と力技でもプログ
  21. ラムを完成させる事ができますが、中規模プログラムともなるとそれだけで完成
  22. させる事は困難です。見え見えの結論ではありますが、やはり中規模プログラム
  23. を作るには、
  24.  
  25.     ・設計
  26.  
  27.   が重要です。では設計とは何でしょう。Ｃ言語の場合、
  28.  
  29.     ・関数の機能（どのような機能の関数を作るか）
  30.     ・関数の依存関係（どの関数がどの関数を呼んでいるか）
  31.     ・データ構造（配列、構造体、テーブル、リスト…）
  32.  
  33.   をプログラミングに入る前にしっかりと決めておく、それが設計です。集団作
  34. 業を行う職業プログラマーであれば、これらの設計は「仕様書」として書き留め
  35. て紙にプリントアウトして上司なりクライアントなりに提出するのでしょうが、
  36. 今回の場合のように作ったプログラムを雑誌に載せて公開しよう、という場合は
  37. そこまでする必要はないと思います。しかも今回は作るのがゲームプログラムと
  38. いう事もあり、実際に遊んでみて仕様をどんどん変えていくという事が想定され
  39. ます。その度に仕様書を書き換えていくのは大変ですし、仕様書の管理も大変で
  40. す。
  41.  
  42. 　そこで一番良いのは（楽なのは）、
  43.  
  44.     ・ソースプログラムが仕様書になっている
  45.  
  46.   という事だと断言してしまいましょう。これならば不精なプログラマーでもな
  47. んとかなる範囲です。具体的にはやはりソースにコメントを付けておく事でしょ
  48. う。
  49.  
  50.     ・関数の機能に関するコメント
  51.     ・関数の引き数／返り値に関するコメント
  52.     ・変数の使用目的のコメント
  53.  
  54.   をこまめに付けておくだけでも随分違います。これらのコメントが適切に付け
  55. てあればソースを眺めているだけでなんとなく仕様が頭に入って来ることでしょ
  56. う。
  57.  
  58.  
  59. 　話がだいぶそれてきましたが、この項での結論は、
  60.  
  61.     ・設計が重要
  62.     ・仕様書を書け、もし面倒ならばソースが仕様書になるよう努力する
  63.  
  64. 　という２点です。
  65.  
  66.  
  67.  
  68. ▼ ボトムアップかトップダウンか
  69.  
  70.  
  71.   では今回のお題であるシューティングゲームの構造について考察します。手元
  72. にシューティングゲームを用意して画面をよーく眺めて下さい。シューティング
  73. ゲームにはどのような処理が必要でしょうか。
  74.  
  75.     ・ジョイスティックに合わせて自機が移動する
  76.     ・ショットボタンを押すと弾が発射される
  77.     ・弾が敵に当たると敵が爆発する
  78.     ・敵が爆発すると得点が入る
  79.     ・ある程度進むとボスキャラが登場する
  80.     ・ボスキャラを倒すと１面クリア
  81.     ・全面クリアすると終了もしくは２周目に突入
  82.     ・等々…
  83.  
  84.   このような処理をプログラムすることにより、ゲームは完成します。このよう
  85. に必要な小さな処理（モジュール）を組み合わせていくのがボトムアップと呼ば
  86. れる手法です。ボトムアップは処理内容が具体的で判り易い反面、やはり全体の
  87. 見通しが悪くなるという欠点があります。
  88.  
  89.   トップダウンという設計手法は全体の構造を把握した上でそれらを小さな構造
  90. に切り分けていくという手法です。見通しが良い反面、最初のうちは対象が大き
  91. すぎて途方に暮れてしまうという欠点があります。でもまあそれは自分の頭で全
  92. て考えて構造を作るという話。シューティングゲームに関しては比較的ポピュラー
  93. な構造が知られていますので、今回も基本的にはそれに従っていく事にします。
  94. 但し既に用意されているライブラリ（XSP関連、IOCS関連等）が既にある事から、
  95. これらのライブラリを活かす方向で作っていくので完全なトップダウンというわ
  96. けではありません。現実的にはこのような「既存の資産を活かした上でのトップ
  97. ダウン」が多いのではないでしょうか。また、トップダウンによってある程度全
  98. 体の構造が見えてきたらボトムアップの手法で各モジュールを作成していく事も
  99. 有効ですので今回はこの手法を採用することにします。
  100.  
  101.  
  102.  
  103. ▼ 構造と要素
  104.  
  105.  
  106.   次に各関数の構造を見ていくのですが、ここで本文は以下の２つに分岐します。
  107.  
  108.     ・要素研究
  109.     ・構造研究
  110.  
  111.   要素研究では既存の関数（と、その組み合わせ）で何ができるかという事を研
  112. 究します。例えば「ジョイスティック入力ルーチン」「画面モード設定ルーチン」
  113. 「スプライト標準ルーチン」等々。プログラマーにとって初めての技術をいきな
  114. り本番のプログラムに導入すると取れないバグの元になるので予め小さなサンプ
  115. ルプログラムで研究しておこうという魂胆です。先ほどの議論で言うところのボ
  116. トムアップ的な観点です。
  117.  
  118.   構造研究は各関数をどのような構造にするかの研究です。
  119.  
  120.   要素と構造は密接に関係しあっているため、どちらかを先に済ませるという事
  121. は困難です。「どのような要素を研究すれば良いか」は構造が決まっていないと
  122. わかりませんし、逆に「どのような構造にすれば良いか」を知るためには各要素
  123. がある程度わかっている必要があります。卵が先か鶏が先か…のような問題なの
  124. ですが、ここは思い切って要素研究を先に行ってしまいます。「何故このような
  125. 要素が必要なのか？」という疑問が湧くことがあるかと思いますが、それは後ほ
  126. どの構造研究によって明らかにされます。
  127.  
  128.  
  129.  
  130. （ＥＯＦ）
  131.